Method and apparatus for flexible balance management using reservation consumption

ABSTRACT

A method, system, and computer-program product for flexible balance management using reservation consumption are disclosed. For example, a method according to embodiments of the methods and systems disclosed herein includes receiving a request message and, in response to the receiving the request message, updating a consumed reservation balance.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present patent application claims priority to Provisional PatentApplication Ser. No. 61/884,661, filed Sep. 30, 2013, which is herebyincorporated by reference herein, in its entirety and for all purposes.

FIELD OF THE INVENTION

The present invention relates to charging for services, and, moreparticularly, to a method and system for flexible balance managementusing reservation consumption.

COPYRIGHT NOTICE/PERMISSION

Portions of this patent application contain materials that are subjectto copyright protection. The copyright owner has no objection to thefacsimile reproduction by anyone of the patent document, or the patentdisclosure, as it appears in the Patent and Trademark Office file orrecords, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

Service providers are experiencing ever-growing service usage bysubscribers. A service provider implements a charging system in whichsubscribers are charged for their service usage. An example chargingsystem may implement a policy and charging control solution, such asthat developed under 3GPP™ (3^(rd) Generation Partnership Project) IMS(Internet Protocol Multimedia Subsystems) and provides a new standardfor charging system business models.

In addition to overall data volume, mobile connected digital devices(e.g., mobile devices such as smart phones and tablets) and theapplications that run on them are also driving a change in consumerbehavior. The manner in which consumers interact with one another atwork, home, and leisure has changed dramatically within the last decade,prompting a new term to describe consumer behavior—the digitallifestyle. The digital lifestyle also introduces a multitude of newplayers within the communications landscape, including the so calledover-the-top (OTT) providers, on which consumers rely within their dailylives, and often trust and admire.

The digital lifestyle, in turn, has characteristics that reflect theattitudes of consumers immersed in this new economy. Consumers expect tobe “always on,” that is, they expect to be constantly connected, nomatter what their location or device they happen to be using. Along withthe instant gratification expected from such a real-time communicationsenvironment, consumers also require a certain amount of personalizationand control. They want service plans and tariffs that correspond and aretailored to their particular lifestyle, and they want the control to beable to adjust their plans whenever they wish. And, they expect thattheir experience with their service provider to be simple, easy, andpredictable, with no surprises.

The digital world in which we live, work, play, and socialize has thuscreated immense opportunities for communications service providers,however serious pressures and challenges must be overcome.Communications service providers understand, embrace and tackle thosechallenges head-on will be the ones that thrive, as revenueopportunities are abundant for communications service providers in thisnew digital economy.

Service providers (e.g., telecommunications operators and the like)commonly provide pre-paid services to their customers (commonly referredto as subscribers). Such pre-paid services can take the form “freeminutes” (e.g., credit for so many minutes of calls (or a dollar valuetherefor, purchased on a monthly basis, for example), “free megabytes”(e.g., credit for a given amount of data usage, purchased on a monthlybasis, for example), “free messages” (e.g., credit for some number oftexts, purchased on a monthly basis, for example), and the like, orwhere the customer pre-pays a certain amount into their account in orderto hold a credit balance, which is then used in order to provideservice. However, traditional approaches to maintaining and providinginformation regarding subscribers' accounts and their use of suchservices has failed to keep pace with innovations in this area, and thushas failed to meet the needs and expectations of subscribers and serviceproviders alike.

SUMMARY OF THE INVENTION

In one embodiment, a method, system, and computer-program product forflexible balance management using reservation consumption are disclosed.For example, a method according to embodiments of the methods andsystems disclosed herein includes receiving a request message and, inresponse to the receiving the request message, updating a consumedreservation balance.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings.

FIG. 1A is a simplified block diagram illustrating an example of acharging timeline.

FIG. 1B is a simplified block diagram illustrating an example of anothercharging timeline.

FIG. 2 is a simplified block diagram illustrating an example of anetwork architecture that includes a charging system according toembodiments of the methods and systems disclosed herein.

FIG. 3 is a simplified block diagram illustrating an example of anetwork architecture, according to embodiments of the methods andsystems disclosed herein.

FIG. 4 is a simplified block diagram illustrating an example of acharging architecture, according to embodiments of the methods andsystems disclosed herein.

FIG. 5 is a simplified block diagram illustrating an example of activeand consumed balance reservations, according to embodiments of themethods and systems disclosed herein.

FIG. 6 is a simplified block diagram illustrating an example of a set ofcharging communications, according to embodiments of the methods andsystems disclosed herein.

FIG. 7 is a simplified flow diagram illustrating an example of acharging process, according to embodiments of the methods and systemsdisclosed herein.

FIG. 8 is a simplified flow diagram illustrating an example of a processfor setting up a subscriber account and services, according toembodiments of the methods and systems disclosed herein.

FIG. 9 is a simplified flow diagram illustrating an example of a processfor processing one or more new sessions, according to embodiments of themethods and systems disclosed herein.

FIG. 10 is a simplified flow diagram illustrating an example of aprocess for initializing a new session, according to embodiments of themethods and systems disclosed herein.

FIG. 11 is a simplified flow diagram illustrating an example of aprocess for processing and responding to an update message, according toembodiments of the methods and systems disclosed herein.

FIG. 12 is a simplified flow diagram illustrating an example of aprocess for processing and responding to an end session message,according to embodiments of the methods and systems disclosed herein.

FIG. 13A is a simplified block diagram illustrating an example of acharging timeline, according to embodiments of the methods and systemsdisclosed herein.

FIG. 13B is a simplified block diagram illustrating an example ofanother charging timeline, according to embodiments of the methods andsystems disclosed herein.

FIG. 14 is a simplified block diagram illustrating an example ofcharging system objects, according to embodiments of the methods andsystems disclosed herein.

FIG. 15 is a simplified block diagram illustrating an example of abalance component, according to embodiments of the methods and systemsdisclosed herein.

FIG. 16 is a simplified block diagram illustrating an example of abalance reservation structure, according to embodiments of the methodsand systems disclosed herein.

FIG. 17 is a simplified block diagram illustrating an example of atimeline, in which a long-lived data session is depicted, according toembodiments of the methods and systems disclosed herein.

FIG. 18 is a block diagram depicting a computer system suitable forimplementing aspects of systems according to embodiments of systems suchas those disclosed herein.

FIG. 19 is a block diagram depicting a network architecture suitable forimplementing aspects of systems according to embodiments of systems suchas those disclosed herein.

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the systems describedherein and equivalents thereof, as defined solely by the claims, willbecome apparent in view of the examples described in the detaileddescription set forth below.

DETAILED DESCRIPTION

Introduction

A charging system according to embodiments of the methods and systemsdisclosed herein addresses the needs of subscribers and serviceproviders by providing mechanisms and functionality supporting theconcept of a consumed balance reservation, as well as other relatedconcepts (e.g., active balance reservation, communications supportingsuch features, systems designed to support such features andcommunications, and the like). Such approaches provide advantages suchas allowing a billing system to notify the subscriber that their balancehas crossed a defined threshold (based on consumed balance reservationsand/or active balance reservations). Such approaches can also be used toallow service providers to recognize the revenue earlier than wouldotherwise be the case, and to allow service providers to apprisesubscribers of such usage more accurately and in a more timely fashion.In so doing, such solutions provide balance transparency to thesubscriber and accurate notification of balance thresholds based ontheir actual usage of data during the course of ongoing sessions. Suchsystems also provide operators with the ability to classify revenue asearned earlier than without this capability.

In the provision of pre-paid services, the operator (service provider)receives a request for service (also referred to as an authorizationrequest) from the network session controller (e.g., a mobile switchingserver (MSC) in a Global System for Mobile Communications (GSM) network)and the operators charging and billing platform responds by granting aquota of balance which is reserved from the subscriber's balance so thatother services (e.g., streaming video) can simultaneously access thesame subscriber balance without risk of consuming more balance than isavailable. Long running sessions, which are becoming more and morecommon with always-on data services, result is large reservations ofbalance. These reservations cannot be considered as committed usageuntil the session is terminated and until terminated the revenue thatwould accrue from that usage cannot be recognized as earned (in thefinancial sense). Also, reserving extremely large quantities for longrunning sessions means that other services wishing to use the samebalance might not have access to enough balance due to the largeoutstanding reservation. Notifications of balance thresholds is alsobased solely on terminated sessions which limits the transparency to thesubscriber of their current financial position. Service providers mustperiodically cut long running sessions in order to be able to recognizethe revenue for the usage already consumed by their subscribers whichcan potentially result in a reduced customer experience.

Example Systems and Processes

FIG. 1A is a simplified block diagram illustrating an example of acharging timeline 100. Charging timeline 100 illustrates certain of theproblems that can be encountered by charging systems. As can be seen inFIG. 1A, a simplified version of such situations (and depicted thuslyfor purposes of clarity), time proceeds from a time t₀ through t₆ (andbeyond) on an X-axis of charging timeline 100, while charges range fromzero to twelve (and beyond) on a Y-axis of charging timeline 100. Alsodepicted in FIG. 1A is a credit limit 110, which indicates a maximumamount of charges allowable for the given subscriber account. In thisregard, a subscriber may elect to set a balance threshold (depicted inFIG. 1A as a balance threshold 115), and in so doing, request an alertof some sort, indicating that the subscriber's current balance hasexceeded such a threshold.

In the scenario depicted in FIG. 1A, the subscriber's account beginswith an opening balance (depicted in FIG. 1A as a committed balance 120)and an available balance (depicted in FIG. 1A as an available balance125). As can be seen in FIG. 1A, available balance 125 is the amount ofcredit available in the subscriber's account, up to the account's creditlimit (depicted in FIG. 1A as credit limit 110). Viewed another way,committed balance 120 and available balance 125, taken together,aggregate to credit limit 110 (as is depicted in the example in FIG. 1Aat time t₀). At a time subsequent to time t₀, the subscriber initiates acommunications session (e.g., by initiating a voice call using a cellphone). Thus (e.g., at a time t₁), the charging system receives anindication of this event, and begins its accounting for such service. Inresponse, the charging system reserves a balance reservation in a givenamount (e.g., an amount indicated in the authorization request), whichis depicted in FIG. 1A as balance reservation 130, and sends a reply,indicating that the requested balance reservation has been reserved andthat the request has been granted.

The subscriber's communications session (voice call) proceeds until asubsequent time, at which point the communications session ends, and theportion of the balance reservation (balance reservation 130) actuallyused in the communications session, is committed. Such a situation isdepicted in FIG. 1A at a time t₂, at which point the portion of balancereservation 130 that has actually been used is accounted for (depictedin FIG. 1A at committed balance 134). The unused portion of balancereservation 130 thus appears as unused balance reservation 136. As willbe appreciated, while unused balance reservation 136 is shown at time t₂as part of the charging of the used portion of balance reservation 130(i.e., committed balance 134), unused balance reservation 136 is, infact, simply returned to available balance 125 (as appears at time t₃).

At some time subsequent to time t₃, the subscriber may initiate anothercommunications session (another voice call, in this example), at whichpoint the charging system will begin accounting for this newcommunications session. At this juncture, the charging engine receivesan authorization request, and as before, reserves the requested amountand grants the request (depicted in FIG. 1A as occurring at a time t₄).In so doing, the charging engine reserves a balance reservation 140. Ata subsequent point in time during the communications session, additionalbalance may need to be reserved. Such a case is depicted as occurring ata time t₅, at which point, the charging system reserves and grants anadditional amount of balance reservation (depicted in FIG. 1A as abalance reservation 142).

As can be seen in FIG. 1A, the total amount of balance potentially usedin this scenario at time t₅ is the aggregation of committed balance 120,committed balance 134, balance reservation 140, and balance reservation142, which, at least potentially, exceeds balance threshold 115.Unfortunately, while such an aggregation could exceed balance threshold115, there is no way to determine definitively whether balance threshold115 has been exceeded until the subscriber's communications session endsand the amount used are committed, because, in the posited scenario, thetotal balance ultimately used will depend on the amount of balance usedby the subscriber's service usage with respect to balance reservation140 and balance reservation 142. In the scenario posited in FIG. 1A, infact, upon the communications session being closed (the voice callended), just such a situation arises. As can be seen (at time t₆), amessage indicating the end of the communications session is receivedthat specifies the amount of balance reservations 140 and 142 used,amounts to a committed balance 144. When committed balance 144 isaggregated with committed balances 120 and 134, it can be seen thatbalance threshold 115 is exceeded. Only at this juncture can thesubscriber be alerted to that fact, too late for the subscriber toaddress the situation.

FIG. 1B is a simplified block diagram illustrating another example of acharging timeline. In a fashion similar to that described in connectionwith FIG. 1A, FIG. 1B depicts a charging timeline 150 with time on itsx-axis and charges on its y-axis. Also as before, charging timeline 150indicates a credit limit 154 (in this case, 11 units), and a balancethreshold 152 (in this case, 8 units). As before, the scenario depictedin FIG. 1B begins with an opening balance (depicted in FIG. 1B as acommitted balance 156), and, in view of credit limit 154, an availablebalance (depicted in FIG. 1B as an available balance 158).

The scenario depicted in FIG. 1B begins, as before, and continues to apoint at which a subscriber opens a session (e.g., by initiating a voicetelephone call via cellular telephone) at a time t₁. At time t₁, thecharging system receives a request for a balance reservation and, inresponse, reserves a balance reservation 160 and sends a responseindicating that the requested balance reservation has been reserved. Inthe manner noted previously, as the session continues, additionalbalance reservations may be made. Thus, at time t₂, the charging systemmakes a second balance reservation (depicted in FIG. 1B as a balancereservation 165) and sends a message indicating that the reservation hasbeen granted, in response to a request therefor.

The subscriber's communications session (e.g., cellular telephone call)proceeds in this fashion, with additional balance reservations beingmade as needed, within the constraints presented by the applicablelimits (e.g., credit limit 154). An issue arises in this regard when abalance reservation should exceed such a limit. This sort of scenario isdepicted in FIG. 1B at a time t₃, at which point an attempt is made toreserve a balance reservation that exceeds the applicable limit (in thescenario depicted in FIG. 1B, credit limit 154). This is depicted inFIG. 1B as an attempted balance reservation 170, which can be seen toexceed credit limit 154, when aggregated with opening balance 156,balance reservation 160, and balance reservation 165. That being thecase, the charging system maintains available credit 158 at the samelevel as time t₂ (as depicted in charging timeline at a time t₄, shownprimarily for purposes of this description). In view of suchcircumstances, the charging system may be forced to terminate thesession (e.g. disconnect the cellular telephone call), or,alternatively, allow for a new attempt at a balance reservation, but, ineither case, will send a response indicating that the request could notbe granted (and so, is being denied). The latter scenario, in which abilling reservation 180 is successfully reserved by the charging system,is depicted as occurring as a time t₅, in response to a renewed requesttherefor. The charging system thus reserves a balance reservation 180(reducing the available balance 158), and sends a message granting the(renewed) request. Subsequent to time t₅, the session closes (e.g., byway of the subscriber ending the telephone call), having not beenterminated by the earlier failed reservation.

At this juncture, in the scenario depicted in FIG. 1B, the portion ofbalance reservations 160, 165, and 180 actually used during thecommunications session is now committed to the subscriber's balance as acommitted balance 190 by the charging system (as well as associatedbusiness systems). Such a scenario gives rise to a number of issues,among them the subscriber not being alerted to balance threshold 152having been exceeded, and the possibility that the earlier failedreservation was denied unnecessarily. In the former case, as before, theaggregate of opening balance 156, and committed balance 190 exceeds thethreshold set by the subscriber (balance threshold 152), which can beproblematic for the subscriber. In the latter case, if the portion ofbalance reservations 160 and 165 had been even 1 unit less than the sumtotal of their amounts (i.e., 4 units, instead of 5 units), attemptedbalance reservation 170 could have been successfully reserved, avoidingthe additional communications overhead, time, and other resourcesinvolved in denying the original request. And this is to say nothing ofsuch a denial resulting in the termination of a communicationssession—one can envisage the anger with which a subscriber would greettheir telephone call suddenly ending, particularly in light of a laterdetermination that the termination was, in fact, unnecessary.

FIG. 2 is a simplified block diagram illustrating an example of anetwork architecture that includes a charging system according toembodiments of the methods and systems disclosed herein. Thus, FIG. 2depicts a network architecture 200 as including a communications network(depicted in FIG. 2 as a communications network 210), which isconfigured to couple numerous of the elements of network architecture200 to one another. In that regard (and among a number of suchfacilities provided thereby), communications network 210 supportscommunications between a number of subnetworks (depicted in FIG. 2 assubnetworks 220(1)-(N)). Subnetworks 220(1)-(N), in turn, can include anumber of components, such as one or more clients (depicted in FIG. 2 asclients 225(1)-(N)) and/or servers (depicted in FIG. 2 as servers230(1)-(N)). Clients 225(1)-(N) and/or servers 230(1)-(N) can, forexample, be implemented using computer systems such as those describedgenerically in connection with FIGS. 18 and 19. Communications network210 thus communicatively couples subnetworks 220(1)-(N) to one another,thereby allowing clients 225(1)-(N) and servers 230(1)-(N) tocommunicate with one another (and can, in certain embodiments, providefor the servers of subnetworks 220(3) and 220(N), for example, tooperate as cloud-based server systems). As is depicted in FIG. 2,clients 225(1)-(N) can be communicatively coupled to one another and toservers 230(1)-(N) as part of one of subnetworks 220(1)-(N), or directlyvia communications network 210. Similarly, servers 230(1)-(N) can becoupled via communications network 210 via a direct connection tocommunications network 210, or as part of one of subnetworks 220(1)-(N).

Network architecture 200 also provides for communication viacommunications network 210 using one or more other devices. Such devicescan include, for example, a general packet radio service (GPRS) client240 (e.g., a “smart phone,” a “tablet” computer, or other such mobiledevice), a secure web client (e.g., a laptop computer running a securehypertext transfer protocol (hypertext transfer protocol secure, orHTTPS), and depicted in FIG. 2 as an HTTPS client 250), and a basiccellular phone (e.g., using standard texting or other communicationprotocols, and depicted in FIG. 2 as a simple messaging service (SMS)client 260). Support for GPRS clients, SMS clients, HTTP clients, andthe like thereby provide users with communication functionalityaccording to an embodiment in a mobile environment. SMS client 260 cancommunicate via communications network 210 via several channels. SMSclient 260 can communicate directly, for example, with a gateway 265,which, in turn, communicates with communications network 210 via amessaging gateway 267 and, optionally, elements within subnetwork220(3), for example. Alternatively, SMS client 260 can, via gateway 265,communicate with subnetwork 220(3) (and so, communications network 210)via public messaging services 270 to which gateway 265 and subnetwork220(3) are connected. As is also depicted in FIG. 2, a client 225(4) isalso able to communicate via communications network 210 by way of publiccommunication services 270 and subnetwork 220(3).

In order to support the aforementioned communications, as well as othercommunications within network architecture 200 according to variousembodiments, subnetwork 220(3) includes a charging system 280, as wellas (optionally) providing for a number of clients and/or other servers(not shown), in the manner of subnetworks 220(1)-(N). Charging system280 supports communications within network architecture 200 by way ofreceiving usage information from and providing control information tothe elements of network architecture 200, maintaining usage information,and performing other such functions. Such usage information can include,for example, accounting information, service usage, and other relevantinformation, as may relate to voice telephone calls, data transfers,messaging, and other such communications, as may occur between variousof the elements of network architecture 200.

Charging system 280 includes a number of elements in support of thesefunctions. Such elements include a charging engine 282, which is centralto the functionality provided by charging system 280. Charging engine282 provides information to and receives information from other elementsof charging system 280, which can include, for example, a policy system284, a mediation system 286, a pricing design system 288, and businesssupport systems (BSS) 290. In so doing, charging engine 282 providessupport for functions provided by policy system 284, mediation system286, pricing design system 288, and BSS 290. The functionality providedby charging engine 282, policy system 284, mediation system 286, pricingdesign system 288, and BSS 290 are described in further detailsubsequently herein.

Briefly, policy system 284 includes functionality that comprehends thedesign of policies to control operational aspects of charging system 280by defining and enforcing (via, e.g., charging engine 282 and otherelements of charging system 280) policies and rules resulting therefromon the users of services provided via communications network 210 andother elements of network architecture 200. Similarly, pricing designsystem 288 can be used to design and implement pricing structures forthe services provided within network architecture 200 by a serviceprovider, allowing such a service provider to achieve fair pricing fortheir services, while helping to maintaining the profitability of thoseservices. Business support systems 290 interact with charging engine 282in order to allow the service provider to generate invoices, controlaccess to the network, access other elements of charging system 280, andthe like, as well as open, maintain, and close subscriber accounts asneeded.

Mediation system 286 interacts with charging engine 282 in order toprovide functionality related to controlling certain aspects of theprovision of services throughout network architecture 200. Thus, in oneembodiment mediation system 286 receives charging events from elementsof network architecture 200, extracts event attributes, and generates ausage request. Mediation system 286 then submits the usage request tocharging engine 282, which makes the requisite determinations and sendsa usage response, indicating the outcome(s) of those determinations(e.g., granting or denying the usage request), to mediation system 286.Mediation system 286, in turn, interacts with various elements ofnetwork architecture 200 to effect the outcome(s) indicated by chargingengine 282.

As will be appreciated in light of the present disclosure, a serviceprovider such as that described herein (e.g., a telecommunicationservice provider, a shipping service provider, a utility serviceprovider, and the like) provides subscribers with access to one or moreservice products. A service provider can implement a charging systemthat is configured to define and enforce conditions indicating howsubscribers should be charged for service usage. Service providersstrive to provide a quality service experience to subscribers. Serviceproviders can measure the quality of a service by measuring variousobjective aspects of the service, such as by monitoring certainperformance indicators that reflect the quality of the provided service.Example performance indicators in a telecommunications systems such asnetwork architecture 200 include bandwidth (e.g., maximum rate ofinformation transferred), throughput (e.g., actual rate of informationtransferred), latency (e.g., time measured between sending asubscriber's request and receiving a response), jitter (e.g., variationin arrival time of information), and error rate (e.g., number ofcorrupted bits as a percentage of total bits sent). Service providersoften assure subscribers of a quality user experience by specifyingranges or limits of a number of performance indicators in a servicelevel agreement (SLA), where the performance indicators define a minimumguaranteed level of quality for the provided service.

It will be appreciated that, in light of the present disclosure, thevariable identifier “N” is used in several instances in various of thefigures herein to more simply designate the final element of a series ofrelated or similar elements (e.g., subnetworks 220(1)-(N), clients225(1)-(N), and servers 230(1)-(N)). The repeated use of such variableidentifiers is not meant to imply a correlation between the sizes ofsuch series of elements. The use of variable identifiers of this sort inno way is intended to (and does not) require that each series ofelements have the same number of elements as another series delimited bythe same variable identifier. Rather, in each instance of use, variablesthus identified may represent the same or a different value than otherinstances of the same variable identifier.

As will be appreciated in light of the present disclosure, processesaccording to concepts embodied by systems such as those described hereininclude one or more operations, which may be performed in anyappropriate order. It is appreciated that operations discussed hereinmay consist of directly entered commands by a computer system user or bysteps executed by application specific hardware modules, but thepreferred embodiment includes steps executed by software modules. Thefunctionality of steps referred to herein may correspond to thefunctionality of modules or portions of modules.

The operations referred to herein may be modules or portions of modules(e.g., software, firmware or hardware modules). For example, althoughthe described embodiment includes software modules and/or includesmanually entered user commands, the various example modules may beapplication specific hardware modules. The software modules discussedherein may include script, batch or other executable files, orcombinations and/or portions of such files. The software modules mayinclude a computer program or subroutines thereof encoded oncomputer-readable storage media.

Additionally, those skilled in the art will recognize that theboundaries between modules are merely illustrative and alternativeembodiments may merge modules or impose an alternative decomposition offunctionality of modules. For example, the modules discussed herein maybe decomposed into submodules to be executed as multiple computerprocesses, and, optionally, on multiple computers. Moreover, alternativeembodiments may combine multiple instances of a particular module orsubmodule. Furthermore, those skilled in the art will recognize that theoperations described in example embodiment are for illustration only.Operations may be combined or the functionality of the operations may bedistributed in additional operations in accordance with the invention.

Alternatively, such actions may be embodied in the structure ofcircuitry that implements such functionality, such as the micro-code ofa complex instruction set computer (CISC), firmware programmed intoprogrammable or erasable/programmable devices, the configuration of afield-programmable gate array (FPGA), the design of a gate array orfull-custom application-specific integrated circuit (ASIC), or the like.

FIG. 3 is a simplified block diagram illustrating an example of networkarchitecture, according to embodiments of the methods and systemsdisclosed herein. A network architecture 300 such as that depicted inFIG. 3 can include a number of systems and subsystems, some of which arecomparable to those depicted in network architecture 200. For example,network architecture 300 includes a network 310, which communicativelycouples a number of switching subsystems (depicted in FIG. 3 asswitching subsystems 315(1)-(N)) to one another. Switching subsystems315(1)-(N) couple a number of base stations (depicted in FIG. 3 as basestations 320(1,1)-(N,N)) to one another via network 310. In turn, basestations 320(1,1)-(N,N) provide a number of mobile devices (depicted inFIG. 3 as mobile devices 330(1,1)-(M, N)) with access to thecommunications facilities of network architecture 300. Suchcommunications facilities can, for example, be provided in the manner ofvarious ones of mobile devices 240(1)-(N), SMS client 260, clients225(1)-(N), and other such elements of FIG. 2.

In the example depicted in FIG. 3, base stations 320(1,1)-(N,N) provideaccess between ones of mobile devices 330(1,1)-(M,N) using, for example,radio frequency communications. That being the case, base station320(1,N) is depicted as including a base station control unit 340 and atransceiver 345. As can be seen in FIG. 3, transceiver 345 supportswireless communications with mobile devices 330(1,1)-(1,N), and providesthese mobile devices with access to other such mobile devices on thenetwork (e.g., via switching subsystem 315(1) and network 310). Basestation control units such as base station control unit 340 handleconnections (e.g., voice, data, messaging, and other suchcommunications) between various ones of mobile devices 330(1,1)-(1,N),as well as to other elements of network architecture 300. For example,in a wireless (e.g., cellular) telephone system, the signals from one ormore mobile telephones in a given area (typically referred to as a cell)are received at a base station such as base station 320(1,N), which thenconnects the call to other elements of network architecture 300. In sucha case, elements of network 310 can include carrier, microwave radio,and/or switching facilities that connect calls from various ones ofmobile devices 330(1,1)-(M,N) to various others of mobile devices330(1,1)-(M,N).

Next, such a connection transits a switching center such as switchingcenter 350 of switching subsystem 315(1). Switching center 350 performsfunctions such as switching incoming and outgoing voice and dataconnections, as well as interacting with a session controller 355 ofswitching subsystem 315(1), in order to support communications (e.g.,voice calls) and tracking of such activity for purposes of billing andthe like. To this end, session controller 355, as its name implies,controls communications sessions transiting switching centers such asswitching center 350, and supports tracking of communications sessionsfor billing purposes (e.g., charging), communications sessionmonitoring, voice and data traffic management, failure detection andrecovery, and other such functions.

Switching subsystem 315(1), via session controller 355, communicateswith a mediation system 360. Mediation system 360, depicted in FIG. 3 asan online mediation system, provides functionality related to theconversion of data of certain data types to other data types, typicallyfor billing purposes, and can be implemented using one or more servers(a server, in turn, being implemented using one or more computingdevices). A mediation system such as mediation system 360, among otherfunctions, processes usage detail records (more specifically, calldetail records (CDRs)) and handle information regarding voice and datacalls such as call duration, peak time information, and the like.

Mediation system 360 is communicatively coupled to both one or moresession controllers such as session controller 355, and a chargingengine 370 (described subsequently). When a subscriber wishes to utilizea service, the subscriber's device (e.g., one of mobile devices330(1,1)-(1,N)) attempts to make a connection, resulting in a requestfor the service (a service request) being sent to mediation system 360.Mediation system 360 processes call detail records and other suchinformation received from session controller 355. A message processingservice module within mediation system 360 generates a correspondingusage request and routes the usage request to the appropriate chargingcomponent of charging engine 370. Such a charging request includes apayload that contains information (e.g., from the relevant CDR(s)) inthe form of attributes about the subscriber's service usage, such as thetype of service being utilized and service usage measurements (e.g.,volume-, time-, or event-based service usage measurements), and can beimplemented using one or more servers, as well. In response, chargingengine 370 utilizes the payload to perform the appropriate operations(e.g., charging the subscriber, performing authorization operations,and/or the like). Charging engine 370, which can perform chargingfunctions for both offline and online charging, receives and operates onthe information received from mediation system 360. Charging engine 370then responds to the service request received from mediation system 360with a response (a usage response) that indicates, for example, whetherthe service request is granted or denied.

In certain embodiments, charging engine 370 also provides informationregarding communications sessions to a business support system (BSS)380. BSS 380, in turn, includes a billing and revenue management (BRM)system 390 and a customer relationship management (CRM)/ordermanagement/order fulfillment system 395. Thus, in addition tomaintaining information about and performing calculations regardingsubscriber's use of services within network architecture 300, chargingengine 370 provides communication providers with the ability to not onlytrack usage of their network, but also control such usage. Thus,charging engine 370 provides business support system 380 withinformation regarding, for example, call detail records, for purposes ofbilling, accounting, and the like. As will be apparent in light of thepresent disclosure, billing and revenue management system 390 uses thisinformation to generate information to subscribers, provide subscriberswith information as to their accounts, and other such client-facingfunctions. Access to billing and revenue management system 390 can behad via CRM/ON/OF system 395, which provides a variety of functionsrelevant to the provision of services to subscribers, as well assubscriber access to accounts (e.g., via the web, or the like).

For service providers that provide subscribers with communicationsservices using network architectures such as network architecture 300,latency in processing communications transactions is unacceptablebecause service quality is dependent upon the speed with which a servicetransaction (or an exchange of a usage request message and a usageresponse message) is completed, such as a service that cannot beprovided to a subscriber until the subscriber or particular serviceusage (e.g., an event) is authorized by a charging engine. For example,a subscriber may not be able to make a cellular telephone call under apre-paid service plan until the charging engine verifies that thesubscriber has enough credit to initiate the call. In such a chargingsystem, a service provider may define a performance goal of a maximumservice transaction latency time of 50 milliseconds in the chargingsystem, where latency of a service transaction is measured from the timea service request is sent to the charging engine from the mediationsystem until the time a corresponding service response is received atthe mediation system from the charging engine.

And as the volume of communications sessions increases, the demandsplaced on such systems only increases, causing delays to lengthen andthroughput levels to fall. Further, as the number of subscribersincreases, the number of service transactions that need to be processedby the charging engine also increases, which in turn requires additional(and expensive) computing resources to monitor the latency of thoseservice transactions. As a result, processing latencies increaseexponentially, as the number of subscribers (and so servicetransactions) grew. For example, with 10 subscribers executing 10service transactions each, 100 total service transactions would need tobe processed. With 10 times that number of subscribers (100 subscribers)and service transactions (100 per subscriber), the total number ofservice transactions balloons to 10,000. As will be appreciated, then,subscriber experience must remain a focus when designing such systems.

Further, not only is subscriber experience impacted by the speed withwhich such transactions are processed, but such communications aretypically held to requirements set out in any number of applicablestandards. The problems caused by the aforementioned exponential growthare only compounded when the need to service such transactions quicklyto meet the requirements of standards is taken into account. Forexample, the relevant time constraints for certain communicationssessions are often spelled out in widely-promulgated internationalstandards, such as the 50 ms, 230 ms, and 2 s constraints mandated toavoid Carrier Group Alarms (CGAs) in the case of voice telephone callsadhering to various relevant standards (e.g., including, but not limitedto, 3GPP™ IMS (and more particularly, 3GPP™ (Phases 1 and 2, andReleases 96-99 and 4-11)), Bell Communications Research (Bellcore; nowTelcordia) General Requirements and Industry Standards (GR) GR-499,Bellcore GR-253 (including GR-253: Synchronous Optical Network (SONET)Transport Systems, Common Generic Criteria, Issue 5 [Bellcore, October2009]), and ANSI (American National Standards Institute) T1.102, and thetiming requirements therein, all of which are included herein byreference, in their entirety and for all purposes). If such increases inload are not addressed by the techniques employed, the processingoverhead incurred while processing an ever-greater number of servicetransactions will slow the charging engine's processing of those servicetransactions, lengthening latency times and reducing throughput. Thus,in the case of time-critical services (e.g., voice telephonecommunications), the number of subscribers and service requests, alongwith the requirements of the relevant standards, quickly results insituations that become unworkable. These and other limitations andproblems are addressed by systems according to the present disclosure.

To this end, the computing devices used to implement the servers notedelsewhere herein are therefore typically robust and computationallypowerful. By employing high-performance computing platforms, suchservers maximize throughput, and enable the provision of servicesquickly and efficiently. To this end, these server systems can beimplemented using designs that are built for high-performance, in-memoryoperations. For example, such a server system can be designed to storemultiple terabytes of data directly in memory, thereby providing forfast processing of data and communications based thereon, resulting inresponsive performance that meets the timing requirements of theapplicable technical standards. In one embodiment, such a server systemsupports high-speed main memory of 1 Terabyte (or more, depending on theelement's needs) and 2.4 TB of high-speed second-tier memory (e.g.,FLASH memory or the like) that can support hundreds of thousands ofinput/output operations per second, as well as bandwidth at themulti-gigabytes level. These memory layers are further backed by of harddisk storage (3.6 TBs or more), which is expandable (e.g., using FibreChannel and other such high-speed technologies). Computationally, such aserver system can include a processing package of 40 compute cores withhyper-threading. A generic example of such components is provided inconnection with the discussion of FIGS. 18 and 19, below.

FIG. 4 is a simplified block diagram illustrating an example of acharging architecture, according to embodiments of the methods andsystems disclosed herein. To this end, FIG. 4 depicts a chargingarchitecture 400 in which mediation system 360, charging engine 370, andbilling and revenue management system 390 of FIG. 3 appear. In a mannercomparable to that discussed briefly with regard to FIG. 3, chargingengine 370 acts as a central element of charging architecture 400, aswell as network architecture 300. Various of the communications betweenthese elements are now described in connection with chargingarchitecture 400.

In this regard, mediation system 360, having received a request from,for example, session controller 355, sends a usage request to chargingengine 370 (depicted in FIG. 4 as a usage request 410). As notedelsewhere, mediation system 360 can be implemented using one or moreservers, such as those described above, and can be communicativelycoupled to charging engine 370 and the relevant elements of the givennetwork architecture (e.g., session controller 355) by way of anappropriate communications protocol (e.g., one or more IP (InternetProtocol) networks that utilize a communications protocol such asEthernet, IEEE 802.11x, or some other communications protocol). Thecharging request received can include, for example, a payload thatcontains information in the form of attributes about the subscriber'sservice usage, such as the type of service being utilized and serviceusage measurements (e.g., volume-, time-, or event-based service usagemeasurements). Charging engine 370 and BRM system 390 are configured toutilize the payload to charge the subscriber or perform otherauthorization operations.

Charging engine 370 receives usage request 410 and makes certaindeterminations in relation thereto, and then provides mediation system360 with a usage response 420. For example, mediation system 360 maysend a usage request 410 to charging engine 370, indicating that asubscriber has initiated a voice telephone call and requesting thatcharging engine 370 grant a balance reservation in support of therequest made on behalf of the subscriber's desired communicationsession.

As noted, charging engine 370 is configured to perform operations thatdetermine (or allowed to be determined) charges that arise from asubscriber's service usage. Charging engine 370 can be implemented onone or more processing nodes, where the one or more processing nodes areimplemented on one or more servers (such as on a grid-basedhigh-availability cluster of servers, such as described earlier), andimplemented on one or more computing devices. Charging engine 370includes one or more charging components, each of which is responsiblefor performing a portion of the determinations needed to appropriatelycharge the subscriber for service usage. The charging components ofcharging engine 370 can be implemented on the one or more processingnodes of charging engine 370.

In turn, charging engine 370 responds with usage response 420 (e.g.,granting the subscriber's communication session a balance reservation),thereby allowing the voice call to proceed. In addition, mediationsystem 360 and charging engine 370 may exchange credit control messages430. Such credit control messages can include indications as to the needto terminate a session due to insufficient credit, information regardingthe support of multiple services, origin- and destination-relatedinformation, and other such information. Charging engine 370 alsocommunicates with billing and revenue management system 390, by, forexample, providing billing data (depicted in FIG. 4 as billing data440), while billing and revenue management system 390 can provideinformation regarding subscribers (depicted in FIG. 4 as subscriber data450) to charging engine 370.

FIG. 5 is a simplified block diagram illustrating an example of activeand consumed balance reservations, according to embodiments of themethods and systems disclosed herein. According to such methods andsystems, the concept of a consumed balance reservation is employed toallow for a more accurate, more timely determination of the chargespending against a subscriber's account. By providing features andmechanisms that support the communication and processing of suchinformation, subscribers can be provided with a more accurate view oftheir current balance usage. To this end, then, FIG. 5 depicts a totalbalance reservation 500, an available balance 510, and a committedbalance 520. In the scenario shown in FIG. 5, total balance reservation500 includes an active balance reservation 530 and a consumed balancereservation 540. As will be appreciated, an available balance such asavailable balance 540, as used herein, is the difference between theaggregation of total balance reservation 500 and committed balance 520,and a credit limit 550. A committed balance such as committed balance520, in certain embodiments, represents the previous amounts ofsubscriber balance used in one or more preceding communicationssessions, which has been committed to the accounting system tasked withaggregating and maintaining such information.

As is described in further detail elsewhere herein, active balancereservation 530 and consumed balance reservation 540 allow asubscriber's account balance(s) to be monitored in a variety of ways.For example, by providing mechanisms such as those described herein,information regarding the consumed portion of total balance reservation500 (consumed balance reservation 540) can be used to more closely tracka subscriber's service usage by making available information regarding asubscriber's service usage earlier in the process of accountingtherefor, and so allow that information to be employed in more usefuland meaningful ways. Thus, consumed balance reservation 540 representsthat amount of account balance (e.g., of one or more previous activebalance reservations) actually having been consumed during thecommunications session for which such (active) balance reservations weremade. By contrast, active balance reservation 530 represents that amountof account balance that has been reserved (e.g., in response to a usagerequest), in certain embodiments. However, at a point in time subsequentto that represented in FIG. 5, some portion (or all) of active balancereservation 530 will have been consumed, in a manner comparable to theprocess that gave rise to total balance reservation 500 (though, asdepicted in FIG. 5, only committed balance 540 has been committed at thepoint in time depicted therein). At that subsequent point in time, amessage received (e.g., by the given charging engine) can be used todetermine (e.g., by an indication therein) the amount of active balancereservation 530 that was consumed by the communications session inquestion. The amount of active balance reservation 530 thus consumedbecomes the next consumed balance reservation, with the unused balancereservation remaining being “returned” to available balance 510. As willbe discussed in further detail subsequently, such a process proceedsuntil, for example, the communications session ends, at which point theconsumed reservation balances are committed.

FIG. 6 is a simplified block diagram illustrating an example of a set ofcharging communications, according to embodiments of the methods andsystems disclosed herein. The set of charging communications depicted inFIG. 6 (charging communications 600) can be understood with reference tothe elements or charging architecture 400, as depicted in FIG. 4, andnetwork architecture 300, as depicted in FIG. 3. In this regard,charging communications 600 occur between a session controller 610, acharging system 620, and a subscriber 630. As will be appreciated inview of network architectures 300 and 400, among other such figuresherein, the charging communications depicted as charging communications600 occur between the various elements thereof.

Charging communications 600 begin with an initiate session message 640,from session controller 610 to charging system 620. Receipt of initiatesession message 640 by a charging system 620 results in the reservationof an active balance reservation in an amount Q. Charging system 620responds to session controller 610 by sending session controller 610 aresponse message 645, indicating that the active balance reservation ofQ has been reserved and granted to subscriber 630. Subsequently, at alater time, for example, session controller 610 sends an update sessionmessage 650 to charging system 620. Such might be the case, for example,in the situation in which a voice call is ongoing. Thus, sessioncontroller 610, on behalf of subscriber 630, requests additional activebalance reservation as the communications session proceeds. Updatesession message 650 indicates to charging system 620 that thecommunications session is ongoing, and that and additional balancereservation is needed. Update session message 650 also includesinformation indicating that, of the last active balance reservation (inthe amount of Q), only a quantity of X was consumed. This is recorded asa consumed balance reservation in the amount of X. In response, chargingsystem 620 sends a response message 655 to session controller 610,granting the communications session an active balance reservation in theamount of Q.

Additionally, in the scenario in which the committed balance ofsubscriber 630, in combination with the consumption of a consumedbalance reservation in the amount of X, exceeds a threshold set by thesubscriber 630, a notification 660 can be sent to subscriber 630,alerting subscriber 630 to the communications session's having exceededthat threshold. As discussed subsequently, various embodiments' use ofbalance thresholds can be based on consumed balance reservations alone,or can include consideration of active balance reservations, as well.Such thresholds can be configured by the user, by the service provider(e.g., for internal use, to set defaults for a subscriber whenconfiguring the subscriber's account, or the like), or by othersinteracting with the given charging system. This allows subscriber 630to better manage their use of the communication network, and allowsservice providers such as those servicing the account of subscriber 630to provide services (and charges therefor) that are in line with theexpectations with their subscribers. Using such an approach, subscriber630 can, in fact, set multiple such thresholds, providing an even finergranularity of control over the subscriber's use of their account (andso, improving the user experience provided by the service provider).

At some later time, session controller 610 sends yet another request tocharging system 620 in the form of an update message 670, which requestsa further balance reservation (in the form of another active balancereservation) in the amount of Q, and also indicates that thecommunications session initiated by subscriber 630 has now consumed anadditional amount of balance, in the amount of Y. Such consumption isreflected in FIG. 6 by consumed balance reservation being equal to atotal of (X+Y). In response to update session message 670 and therequest for an active balance reservation of Q, charging system 620responds with a response message 675, granting the communicationssession managed by session controller 610 an additional active balancereservation in the amount of Q. As will be appreciated in light of thepresent disclosure, the active balance reservations of FIG. 6 compare toactive balance reservation 530 of FIG. 5, while the consumed balancereservations FIG. 6 compare to consumed balance reservation 540 of FIG.5. As will be further appreciated, such requests for further balancereservations can, in the alternative, be denied (e.g., if such a requestwould exceed a credit limit such as credit limit 550 (though certainembodiments can address such situations differently)).

Sometime later in charging communications 600, session controller 610sends an end session message 680, which indicates the end of thecommunications session, and also provides the amount of the last activebalance reservation that was consumed (a consumed balance reservation ofZ), bringing the consumed balance reservation to a total of (X+Y+Z).Charging system 620 acknowledges receipt of this information in aresponse message 690.

As will be appreciated in light of the foregoing, the active balancereservations (and thus, the consumed balance reservations) can betracked throughout a communications session, for different sessions,services, and so on. For example, update session messages and responsemessages can be communicated with regard to any number of differentservices, for example, including voice services, data services,messaging services, and the like. Further, using a mechanism such asthat depicted in FIG. 6 and discussed elsewhere herein, a subscribersuch as subscriber 630 can, in fact, define a number of thresholds, in avariety of ways. In this regard, a subscriber can define multiplethresholds for a given means of communication (e.g., voice calls, datatransfer, messaging, and the like), and/or can define differentthresholds for these various types of communications. Further still, itwill be appreciated that, in light of the present disclosure, suchoperations can be carried out with regard to any number of services,sessions for which can occur sequentially or in parallel, as well ascombinations thereof. It will also be noted that the scenario presentedwith respect to FIG. 6 is comparable to that depicted in FIG. 13A.

FIG. 7 is a simplified flow diagram illustrating an example of acharging process, according to embodiments of the methods and systemsdisclosed herein. The process of FIG. 7 (referred to as a chargingprocess 700) can be performed, for example, in a charging architecturesuch as network architecture 300, or charging architecture 400, and isdiscussed in terms of the elements depicted therein, as examples.Charging process 700 begins with a determination as to whether a requesthas been received (step 710). As depicted in FIG. 7, the process loops,awaiting receipt of a request.

Upon the receipt of a request, a determination is made as to whether therequest is a request for the configuration of one or more new services(step 720). If the request received indicates that a subscriber wishesto establish one or more new services, charging process 700 proceeds toset up the subscriber's account and services for the account, inaccordance with the request (step 730). Such requests can be handled viathe components of a business support system such as BSS 380, forexample. The process of setting up a subscriber's account and theoperations associated therewith are described in further detail inconnection with FIG. 8, below.

Charging process 700 then performs any other accounting operationsneeded to complete processing of the requested services (step 740).After such operations, a determination is made as to whether balanceprocessing is to be continued (step 750). If further balance processingoperations are to be performed, charging process 700 returns to awaitingreceipt of the next request (step 710). Alternatively, if no furtherbalance processing is to be performed (step 750), charging process 700concludes.

In the case in which the request received is for a balance processingoperation other than establishing new services (step 720), chargingprocess 700 proceeds to a determination as to whether the requestreceived is for a new communications session (step 760). If the requestreceived is for a new communications session, the new communicationssession is processed (step 770). As before, once one or more newcommunications sessions have been processed, any remaining accountingoperations related to the requested services are performed (step 740).Also as before, a determination is made as to whether balance processingoperations are to continue (step 750), resulting in charging process 700either looping to await the next request (step 710) or concluding.

If the request received is for neither the configuration of new servicesor for a new session, any other requested processing is performed (step780). As before, charging process 700 then continues to perform anyremaining accounting operations related to the requested services (step740), and makes a determination as to whether balance processingoperations are to be continued (step 750). If balance processingoperations are to continue, charging process 700 loops to await receiptof the next request (step 710), or concludes, as appropriate.

Each of the operations of charging process 700 may be executed by amodule (e.g., a software module) or a portion of a module or a computersystem user using, for example, one or more servers such as thosedescribed elsewhere herein. Thus, the above described method, theoperations thereof and modules therefor may be executed on a computersystem configured to execute the operations of the method and/or may beexecuted from computer-readable storage media. The method may beembodied in a machine-readable and/or computer-readable storage mediumfor configuring a computer system to execute the method. Thus, thesoftware modules may be stored within and/or transmitted to a computersystem memory to configure the computer system to perform the functionsof the module, for example.

Such a computer system normally processes information according to aprogram (a list of internally stored instructions such as a particularapplication program and/or an operating system) and produces resultantoutput information via I/O devices. A computer process typicallyincludes an executing (running) program or portion of a program, currentprogram values and state information, and the resources used by theoperating system to manage the execution of the process. A parentprocess may spawn other, child processes to help perform the overallfunctionality of the parent process. Because the parent processspecifically spawns the child processes to perform a portion of theoverall functionality of the parent process, the functions performed bychild processes (and grandchild processes, etc.) may sometimes bedescribed as being performed by the parent process.

Such a computer system typically includes multiple computer processesexecuting “concurrently.” Often, a computer system includes a singleprocessing unit which is capable of supporting many active processesalternately. Although multiple processes may appear to be executingconcurrently, at any given point in time only one process is actuallyexecuted by the single processing unit. By rapidly changing the processexecuting, a computer system gives the appearance of concurrent processexecution. The ability of a computer system to multiplex the computersystem's resources among multiple processes in various stages ofexecution is called multitasking. Systems with multiple processingunits, which by definition can support true concurrent processing, arecalled multiprocessing systems. Active processes are often referred toas executing concurrently when such processes are executed in amultitasking and/or a multiprocessing environment.

The software modules described herein may be received by such a computersystem, for example, from computer readable storage media. The computerreadable storage media may be permanently, removably or remotely coupledto the computer system. The computer readable storage media maynon-exclusively include, for example, any number of the following:magnetic storage media including disk and tape storage media. opticalstorage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) anddigital video disk storage media. nonvolatile memory storage memoryincluding semiconductor-based memory units such as FLASH memory, EEPROM,EPROM, ROM or application specific integrated circuits; volatile storagemedia including registers, buffers or caches, main memory, RAM, and thelike; and other such computer-readable storage media. In a UNIX-basedembodiment, the software modules may be embodied in a file which may bea device, a terminal, a local or remote file, or other such devices.Other new and various types of computer-readable storage media may beused to store the software modules discussed herein.

FIG. 8 is a simplified flow diagram illustrating an example of a processfor setting up a subscriber account and services, according toembodiments of the methods and systems disclosed herein. FIG. 8 thusdepicts a set of example operations for establishing a subscriberaccount and setting up the services that are to be provided to thesubscriber associated with the account. The process begins with acharging system such as that depicted in FIGS. 3 & 4 obtaining therequisite information regarding the subscriber (step 800). Suchsubscriber information could be obtained by a business and revenuemanagement system via an internal channel such as a customerrelationship management system or by way of an online order managementsystem, and fulfilled through an order management system. Once therequisite subscriber information has been obtained, the subscriber'saccount can be created (step 810). Also obtained is informationregarding the service or services that the subscriber would like theservice provider to provide (step 820). The subscriber's subscriberinformation having been obtained, and the subscriber's account havingbeen created, the subscriber's account can be configured and theservice(s) desired provisioned using the service information thusobtained (step 830). It will be appreciated that such serviceinformation can include thresholds and credit limits such as thosedescribed elsewhere herein.

A determination is then made as to whether the account was created andconfigured successfully (step 840). If the subscriber's account has beencreated and configured successfully, accounting operations associatedwith the creation of the subscriber's account are performed (step 850).Such accounting operations can be performed, for example, by a billingand revenue management system such as BRM system 390 of FIG. 3, and caninclude indications as to use of techniques such as those describedherein, provider-defined credit limits and/or thresholds,subscriber-defined thresholds, and the like. The aforementionedoperations having been successfully performed, an indication is providedto service provider personnel and the subscriber that the subscriber'saccount and services are now ready for use (step 860). The process thenconcludes.

In the event that the subscriber's account was not successfully createdand configured (step 840), a determination is made as to whether serviceprovider personnel (or the subscriber themselves) would prefer to retryaccount creation and/or configuration (step 870). In the event thataccount creation and/or configurations are to be retried, the processreturns to its beginning, and the process proceeds as described earlier.If account creation and/or configuration are not to be retried (step870), the failure in account creation/configuration is indicated (step880), and the process concludes.

FIG. 9 is a simplified flow diagram illustrating an example of a processfor processing one or more new communications sessions, according toembodiments of the methods and systems disclosed herein. The processdepicted in FIG. 9 thus illustrates examples of operations that can beperformed in processing one or more new communications sessions in themanner suggested with regard to FIG. 7. A process for processing one ormore new communications sessions begins with the charging systemprocessing a session initialization message, and sending a responsemessage in response thereto (step 900). As will be appreciated in viewof the present disclosure, the process depicted in FIG. 9 is describedfrom the perspective of a charging system such as charging system 620 ofFIG. 6, but can include interactions with a variety of charging systemcomponents such as those of network architecture 300 and chargingarchitecture 400, including, for example, BSS 380 (including BRM 390),mediation system 360, and charging engine 370. The process of processinga session initialization message and sending a response thereto isdescribed in greater detail in connection with FIG. 10.

Once the communications session has been initialized, a determination ismade as to whether the balance reservation was granted (step 910). Sucha request can be granted, for example, if the subscriber's accountreflects a sufficient amount of available balance and the balancereservation is reserved. At this juncture, a charging system such ascharging system 620 awaits the receipt of a new message (e.g., an updatesession message, an end session message, or other such message) (step920). Until a new message is received, the charging system waits,looping until such time as a new message related to the communicationssession is received. Upon receipt of a new message, a determination ismade as to whether the message received is an update message (step 930).In the case in which the message received is an update message, theupdate message is processed and a response message sent in responsethereto (step 940). An example of the processing of and responding to anupdate message is described in greater detail in connection with FIG.11. Having processed the update message and sent the response message,the charging system returns to awaiting the next request (step 910).

In the event that the message received is not an update message (step930), a determination is made as to whether the message received is anend session message (step 950). If other processing is to be performed(and, thus, the message received is neither an update or an end sessionmessage), other processing, as per the request received, is performed(step 960). The process then proceeds to awaiting a new message (step920). If the message received is an end session message (step 950), theend session message is processed and an appropriate response messagesent (step 970). An example of the processing of and responding to anend session message is described in greater detail in connection withFIG. 12. Processing of the end session message having been completed,the process then concludes.

As noted elsewhere herein, upon receipt of a request, it may bedetermined that the subscriber's account does not have (or no longerhas) a sufficient balance available for the requested balancereservation to be satisfied (step 910). In such a case, the chargingsystem provides an indication that the account's available balance isinsufficient for the request to be granted (step 980) and sends a replymessage denying the request for additional balance reservation (step985). Also in such a case, once the indication has been provided, adetermination is made as to whether to continue awaiting message or toterminate the process (step 990), and proceeds accordingly.

FIG. 10 is a simplified flow diagram illustrating an example of aprocess for initializing a new session, according to embodiments of themethods and systems disclosed herein. FIG. 10 thus depicts an example ofthe operations performed in processing an initialize session messagesuch as initiate session message 640, as noted with regard to FIG. 9.Processing an initialize session message begins with the parsing of theinitialize session message (step 1000), which includes extracting therelevant information from the message. Next, the requesting service isdetermined from the information extracted from the initialize sessionmessage (step 1010). Also determined is an initial balance reservation(step 1020). Such a determination can be based, for example, oninformation from the initialize session message, but can also includeinformation derived from other sources based on information includedwith the initialize session message.

Information regarding the requesting service and initial balancereservation having been obtained, a determination is then made as towhether the initial balance reservation amount is available (step 1030).If the initial balance reservation amount is available, a balancereservation for this initial balance amount is reserved for therequesting service (and thus, setting the active balance reservationamount), based on the information determined from the initialize sessionmessage, and successful reservation of the active balance reservationamount indicated (step 1040). Next, accounting operations associatedwith initiating the service are performed (step 1050). Such operationscan be carried out, for example, by a billing and revenue managementsystem such as BRM system 390. Additionally, any other operations asassociated with initiating the session can be performed at this juncture(step 1060). The communications session having been successfullyinitialized (and the active balance reservation having been reserved),the charging engine sends a response message, indicating grant of therequested balance reservation, to the session controller. Thereservation made and the grant indicated, the initialization process cannow conclude.

Alternatively, if the initial balance reservation amount is unavailablein the subscriber's account (step 1030), an indication that therequested balance reservation could not be reserved is provided (e.g.,within the charging system, but ultimately, to the subscriber and/or theservice provider) (step 1070). As noted earlier, the unsuccessfulreservation of the desired balance reservation amount can either resultin further negotiations between the charging system and sessioncontroller, or can result in the termination (in the present scenario,failed initialization) of the communications session. The requestedinitialization having been unsuccessful, the charging engine sends aresponse message, denying the request, to the session controller. Therequest having been denied, the initialization process concludes.

FIG. 11 is a simplified flow diagram illustrating an example of aprocess for processing and responding to an update message, according toembodiments of the methods and systems disclosed herein. FIG. 11 thusdepicts examples of operations performed in processing an update messagesuch as update session messages 650 and 670, as well as sending aresponse message in response thereto. The process of FIG. 11 begins withthe parsing of the update message (step 1100), which, at least in part,serves to extract the relevant information from the update message. Fromthis information, the requesting service, requested balance reservation,and consumed portion of the earlier balance reservations are determined(step 1105). The charging system then retrieves the committed balance,one or more consumed reservations, and credit limits relevant to thecommunications session at hand (step 1110). The balance amount of theupdated consumed balance reservation is then determined, using theconsumed reservation balance(s) and balance reservation used (step1115). Such a determination can be made in the manner described inconnection with the operations depicted in FIG. 6.

The balance amount of the updated consumed balance reservation andrequested balance reservation are then compared with the credit limitfor the service and account in question (step 1120). A determination isthen made as to whether the relevant credit limit(s) have been exceeded(step 1125). In the case in which the relevant credit limit(s) have notbeen exceeded, the consumed balance reservation in question is updatedappropriately (step 1130). The active balance reservation is then set tothe requested balance reservation, as per the update message received(step 1135).

If one or more thresholds are to be applied to the communicationssession, a threshold thereof is retrieved (step 1140). The retrievedthreshold may, in fact, be one of many such thresholds, and while theprocessing of a given balance reservation request in light of suchthresholds is depicted in FIG. 11 as being sequential in nature,techniques for applying multiple thresholds to such a balance requestare intended to be comprehended by the disclosure presented herein, aswill be appreciated in light of that disclosure. Once the threshold hasbeen retrieved, the updated consumed reservation and requested balancereservation are compared with the thresholds (step 1145). Adetermination is then made as to whether the updated consumedreservation and requested balance reservation exceed the given threshold(step 1150). As will also be appreciated, such determinations caninclude a variety of mathematical relationships (e.g., greater than orequal to) and other determinations, and such comparisons are intended tobe within the scope of the present disclosure. Further, it will beappreciated that such determinations can also be made with respect toonly the consumed reservations, where, for example, the consumedreservations are summed upon receipt of an update message, and that sumcompared to the threshold(s). If the threshold in question has beenexceeded, a message (notification) can be sent to the subscriber,indicating that such is the case (step 1155). If the given threshold hasnot been exceeded (step 1150) or the requisite message sent to theirsubscriber (step 1155), a determination is made as to whether one ormore additional thresholds should be processed (step 1160). As will beapparent in light of the present disclosure, other actions may be takenin response to a determination that a given threshold has not been met,including a notification to the subscriber that the communicationssession should be terminated, a message to the service provider, furtheranalysis of the thresholds, avoiding such further analysis, and othersuch alternatives, which are intended to come within the scope of thepresent disclosure. If further thresholds remain to be processed (step1160), the next threshold is retrieved (step 1140) and the processcontinues. If no further thresholds are to be processed (step 1160), aresponse message is sent, granting the requested balance reservation(step 1170). In so doing, the charging system provides the sessioncontroller with an indication that the requested balance reservation wassuccessfully reserved, and that the communications session can proceed(step 1170). Once any remaining accounting operations and the like havebeen performed for the request being serviced (step 1175), the processconcludes.

In the case in which the credit limit for the account and/or servicebeing provided has been exceeded (step 1125), a message is sent to thesubscriber indicating that the relevant credit limit has been exceeded(step 1180). Further, the charging system can indicate to various onesof the business systems that the credit limit has been exceeded (step1185). Such indication can also be used by a process such as thatdepicted in FIG. 7 as charging process 700. At this juncture, thecharging system sends a response message to the session controllerindicating that the requested balance reservation could not be reserved,and that the request is therefore being denied, as a result of therelevant credit limit having been exceeded (step 1190). The denialhaving been sent, any remaining accounting operations relating to therequest having been serviced (and denied) are performed (step 1175), andthe process concludes.

FIG. 12 is a simplified flow diagram illustrating an example of theprocessing of an end session message and response thereto, according toembodiments of the methods and systems disclosed herein. FIG. 12 thusdepicts examples of the operations that can be performed in processingand end session message such as end session message 680. The processingof an end session message, as depicted in FIG. 12, begins with theparsing of the end session message (step 1200). As with the processingof others of such messages, a determination as to the service andbalance reservation used is made, based on information from the endsession message received (step 1210). Next, a determination is made asto the balance amount of the updated consumed reservation, using theconsumed balance reservation and the balance reservation used (step1220). These determinations having been made, the consumed balancereservation can be updated (step 1230). The updated consumed balancereservation can then be committed to the committed balance (step 1240).Such an operation can be performed, for example, by way ofcommunications between the charging engine (e.g., charging engine 370)and components of the business support system (e.g., BRM system 390). Ifdesired, a message can then be sent to the subscriber, indicatinginformation such as the time that the communications session ended, theamount of consumed balance reservation (i.e., the amount of charges),and the resulting committed balance (e.g., the outstanding balance fortheir account) (step 1250). As response message is then sent from thecharging system to the session controller, confirming the end of thecommunications session (step 1260).

FIG. 13A is a simplified block diagram illustrating an example of acharging timeline, according to embodiments of the methods and systemsdisclosed herein. FIG. 13A thus depicts a charging timeline 1300, inwhich balance reservations, including active balance reservations andconsumed balance reservations, are employed in order to provide thebenefits of such methods and systems. Charging timeline 1300 presentstime on the X-axis and charges on the Y-axis, and includes a creditlimit 1302 and a balance threshold 1304, in the manner of such elementsdescribed previously. At time t₀ on charging timeline 1300, a committedbalance 1310, and available balance 1312 are shown.

In response to a request for a first balance reservation (e.g., asession initialization message or an update message), the chargingsystem reserves an active balance reservation 1315 at time t₁.Subsequently, an update message is received by the charging system,indicating an amount of balance reservation actually consumed (aconsumed balance reservation), for example. This results, at a time t₂,in a consumed balance reservation 1316 (as well as an unused balancereservation 1317). At this juncture, the charging system can grant anadditional balance reservation by an amount that, for example, exceedsneither credit limit 1302, nor balance threshold 1304. Such is the case,for example, at time t₃ of charging timeline 1300, at which point anactive balance reservation 1320 is made. As will be appreciated in lightof the present disclosure, the situation depicted at time t₃ on chargingtimeline 1300 reflects a scenario comparable to that depicted in FIG. 5.In that regard, available balance 1312, active balance reservation 1320,consumed balance reservation 1316, and committed balance 1310 mirrorthose portions of the subscriber's balance, as reflected in FIG. 5.

Moving along charging timeline 1300 to a time t₄, the result of thereceipt of another update message can be seen, reflecting the fact thatactive balance reservation 1320 has now had a portion thereof consumed.This consumed portion appears as consumed balance reservation 1322 (aswell as an unused portion of active balance reservation 1320, depictedas an unused balance reservation 1324). The state of the subscriber'sbalance is depicted at a time t₅ as having a committed balance and aconsumed balance reservation that include committed balance 1310,consumed balance reservation 1316, and consumed balance reservation1322, with available balance 1322 remaining.

At a time t₆, in response to the receipt of an update message, thecharging system goes about granting an active balance reservation 1330.At this juncture in certain embodiments, while such a balancereservation would not exceed the subscriber's credit limit (credit limit1302), the subscriber can be alerted to balance threshold 1304 beingexceeded by the recent balance reservation. It will be appreciated thatsuch an event does not necessarily indicate that balance threshold 1304will be exceeded, but only that balance threshold 1304 could be exceeded(since the amount of active balance reservation 1330 actually consumedis unknown at this point). By the same token, using such an approach,the charging system is able to generate such alerts earlier than basingsuch indications on committed balances/consumed balance reservationsalone.

Since such a balance reservation would not exceed the subscriber'scredit limit (credit limit 1302), even if entirely consumed, thesubscriber (or more typically, the service provider, for the first suchalert (given the timing of such decisions)) can choose to allow thetransaction to proceed, being aware of the possibility that uponconsumption, the total balance could exceed balance threshold 1304.Thus, while the aggregation of committed balance 1310, consumed balancereservation 1316, consumed balance reservation 1322, and active balancereservation 1330 exceed balance threshold 1304, in fact, the actualtotal balance could remain at a level below balance threshold 1304 (anddoes, in fact, as depicted in FIG. 13A). To that end, as depicted oncharging timeline 1300 at a time t₇, the subscriber's balance reflectsan amount that is the aggregation of committed balance 1310, consumedbalance reservation 1316, consumed balance reservation 1322, and aconsumed balance reservation 1332. In such a situation, an unusedbalance reservation 1334 is, in effect, returned to available balance1312.

Subsequently, the next consumed balance reservation of an active balancereservation may, in fact, exceed balance threshold 1304. Such asituation is depicted in FIG. 13A at times t₈, t₉, and t₁₀ on chargingtimeline 1300, where an active balance reservation 1340 at a time t₈results in, when aggregated with consumed balance reservations 1316,1322, and 1332, balance threshold 1304 being exceeded. As noted, such asituation can be handled through the generation of an alert to thesubscriber and/or service provider.

Alternatively (and as noted), such alerts can be generated based on theexisting consumed balance reservations alone. For example, as part ofprocessing an update session message (e.g., update session messages 650or 670), such an alert can be generated upon receipt of that message, ifthe then-current total of the consumed balance reservations andcommitted balance exceed the relevant balance threshold. Suchdeterminations can be made in response to the receipt of an end sessionmessage (at the conclusion of the communications session), as well. Suchis the case at time t₉ on charging timeline 1300, in fact, whereconsumption of portions of active balance reservation 1340 results in aconsumed balance reservation 1342 and an unused balance reservation1344. As can be seen, the aggregation of committed balance 1310, andconsumed balance reservations 1316, 1322, 1332, and 1342 exceed balancethreshold 1304. It is at this juncture that a threshold based only onconsumed balance reservations is triggered. Further, as will beappreciated in light of the present disclosure, such techniques can becombined, with alerts triggered by active balance reservations and/orconsumed balance reservations, in any meaningful combination. Furtherstill, the basis for such alerts can be determined using logicalrelationships therebetween (AND, OR, XOR, and so on), calculations(e.g., determining by what amount a threshold is exceeded), timing (atwhat point in time, how long ago/recently, and so on, that a giventhreshold or thresholds were triggered), among and between service types(e.g., data, text, voice, and so on), and/or other such criteria, as maybe determined from existing information (committed balances, requestedbalance reservations, consumed balance reservations), historicalinformation, and current information (e.g., information included inupdate session requests and end session requests). As will beappreciated in light of the present disclosure, in response to thereceipt of an end session message, consumed balance reservations 1316,1322, 1332, and 1342 can then be committed, for example.

FIG. 13B is a simplified block diagram illustrating an example ofanother charging timeline, according to embodiments of the methods andsystems disclosed herein. FIG. 13B thus depicts a charging timeline1350, which includes, as depicted, a credit limit 1352, a first balancedthreshold 1354, and a second balance threshold 1356. As before, chargingtimeline 1350 begins at a time t₀ where a committed balance 1360 and anavailable balance 1365 are depicted. At time t₁, an active balancereservation 1368 is reserved, as per a request received prior thereto,initiating a communications session. This situation can result in thegeneration of an alert (in the manner noted previously), in the case inwhich active balance reservations are used in this regard.

Next, an update message is received, as indicated in charging timeline1350 at a time t₂, where an indication as to the actual balancereservation consumed is received. Such information is reflected incharging timeline 1350 by a consumed balance reservation 1370 and anunused balance reservation 1372. In this situation, if only consumedbalance reservations are used in generating alerts, an alert need not begenerated (as the aggregate of committed balance 1360 and consumedbalance reservation 1370 does not exceed first balanced threshold 1354).

Next, at a time t₃, a reservation is made in response to the receipt ofan update message, granting a balance reservation beyond first balancethreshold 1354, and second balance threshold 1356, up to credit limit1352. As before, in the case in which active balance reservations areused in this regard, alerts are generated in view of both first balancedthreshold 1354 and second balance threshold 1356 being exceeded.However, since the amount of consumed balance reservation 1370 is known,and given the amount of the active balance reservation made (an activebalance reservation 1374), an excess portion 1375 above credit limit1352 is avoided. Thus, having avoided a situation in which credit limit1352 is exceeded, the overhead, resources, and complications associatedwith such a condition are avoided, saving the service provider money andthe subscriber, aggravation, and so providing the subscriber with animproved user experience.

At a time t₄, balance reservation 1374 is shown as having been subjectto an update message, resulting in a consumed balance reservation 1380and an unused balance reservation 1382. In this situation, if onlyconsumed balance reservations are used in generating alerts, an alert isgenerated (as the aggregate of committed balance 1360 and consumedbalance reservations 1370 and 1380 exceeds first balanced threshold1354). However, as can be seen, not only does the situation at time t₄not result in the exceeding of credit limit 1352 (and the associatedoverhead, resources, and complications avoided), but as consumed balancereservation 1380 demonstrates, such efforts would have been for naughtin any event, the aggregate of committed balance 1360 with consumedbalance reservations 1370 and 1380 being less than even second balancethreshold 1356, much less credit limit 1352.

At time t₅, an active balance reservation 1385 is reserved, whichexceeds second balance threshold 1356. This situation can result in thegeneration of an alert (in the manner noted previously), in the case inwhich active balance reservations are used in this regard.Alternatively, if only consumed balance reservations are used ingenerating alerts, no alert need be generated, as the aggregate ofcommitted balance 1360 and consumed balance reservations 1370 and 1380does not exceed second balance threshold 1356.

However, at time t₆, a consumed balance reservation 1382 exceeds secondbalance threshold 1356, though an unused portion of balance reservation1385 remains (depicted in FIG. 13 as an unused balance reservation1392). An alert is thus generated, indicating that second balancethreshold 1356 has been exceeded, which is handled in a mannercomparable to that described earlier.

At time t₇, then, the consumed balance reservations include consumedbalance reservations 1370, 1380, and 1390, in addition to committedbalance 1360, the aggregate of which exceeds both first balancethreshold 1354 and second balance threshold 1356. At a time t₈, anactive balance reservation 1395 is reserved. Balance reservation 1395 iscompletely consumed, resulting in a consumed balance reservation 1397.Upon the conclusion of communications session (not shown), the totalcommitted balance of the subscriber's account, as per charging timeline1350, stands at nine charging units (the aggregate of committed balance1360 and consumed balance reservations 1370, 1380, and 1390).

FIG. 14 is a simplified block diagram illustrating an example ofcharging system objects, according to embodiments of the methods andsystems disclosed herein. FIG. 14 thus depicts a number of chargingsystem objects (depicted in FIG. 14 as charging system objects 1400),which provide examples of the structures in which balance informationaccording to the methods and systems disclosed herein can be stored andprocessed. That being the case, charging system objects 1400 include asubscriber object 1410, which has as a child object a balance object1420. Subscriber object 1410 maintains information regarding a givensubscriber such as a last name, a first name, and an identificationnumber (examples of which are depicted in FIG. 14). The subscriberinformation maintained in subscriber object 1410 can, for example,include information such as the subscriber information obtained in theprocess depicted in FIG. 8. Balance object 1420 has as child objects,for example, a number of balance item objects (depicted in FIG. 14 asbalance item objects 1430(1)-(N)). In turn, balance item objects1430(1)-(N) have as child objects one or more reservation objects(depicted in FIG. 14 as reservation objects 1440(1)-(N). As can be seenin FIG. 14, balance item objects 1430(1)-(N) maintain informationregarding a subscriber's balances for a given type of service (e.g.,balance item object 1430(1) maintains information regarding a databalance of 50 MB; balance item object 1430(2) maintains informationregarding remaining minutes for voice telephone calls; and balance itemobject 1430(N) maintains information regarding a dollar value balancefor another service (or for use in the subscriber's data or voicesessions)). Similarly, reservation objects 1440(1)-(N) maintaininformation regarding a given communications session using acorresponding service. Thus, for example, reservation object 1440(2)maintains information regarding an active balance reservation (10minutes) and a consumed balance reservation (25 minutes). Suchinformation can be used in the processes described earlier.

Further, the structure of charging system objects 1400 lends itself tofacilitating those processes. A construct such as charging systemobjects 1400 offers, for example, a runtime model that provides fingrained control over and tracking of information through the use ofdomain entities. The persistence model such a construct offers alsoprovides for coarse-grained control over characteristics that may applyto a number thereof, or to others. Benefits include the efficientstorage of and access to such information, and compact representation ofsuch information in the memory and storage systems of charging systemssuch as those described herein.

With regard to the elements of FIG. 14, the subscriber, as indicated inrelation to subscriber object 1410, is one John Smith with a subscriberidentifier of 1234567 (which can be, for example, a telephone number, ofthe form (area_code) 123-4567). Subscriber John Smith's balance, asdepicted in relation to balance item object 1430(N), is currently $50,with an active balance reservation of $10 and a consumed balancereservation of $15 (as indicated in relation to reservation object1440(N)). Further, subscriber John Smith has a “free minute” balance of60 minutes, with an active balance reservation of 10 minutes and aconsumed balance reservation of 25 minutes (in relation to balance itemobject 1430(2) and reservation object 1440(2), respectively). In asimilar fashion, subscriber John Smith has a data balance of 50 MB, withan active balance reservation of 5 MB and a consumed balance reservationof 15 MB (in relation to balance item object 1430(1) and reservationobject 1440(1), respectively).

FIG. 15 is a simplified block diagram illustrating an example of abalance component, according to embodiments of the methods and systemsdisclosed herein. From an object oriented programming perspective, theaforementioned objects can be implemented in a manner such as thatdepicted in FIGS. 15 and 16. For example, a balance component 1500 isdepicted in FIG. 15, and illustrates the relationships between certainof the structures and the methods that employ them. That being the case,balance component 1500 includes a balance factory 1510, which, in turn,includes a balance reservation factory 1520. Balance reservation factory1520, in turn, employs one or more balance implementations 1530 and abalance reservation 1540. In the manner depicted in FIG. 14, balanceimplementation 1530 has associated with it an active reservation 1550.Similarly, balance reservation 1540 has associated with it a balancereservation implementation 1560.

FIG. 16 is a simplified block diagram illustrating an example of abalance reservation structure, according to embodiments of the methodsand systems disclosed herein. That being the case, FIG. 16 depicts abalance reservation structure 1600. Balance reservation structure 1600includes, for example, a balance reservation 1610, and its associateddefinitions. Balance reservation 1610 can be implemented using, forexample, a balance reservation implementation 1620, and its associatedmethods and structures. Further information with regard to variousconstructs, mechanisms, operations, and features appear in Appendix A,which is attached hereto and is incorporated herein by reference, in itsentirety and for all purposes.

FIG. 17 is a simplified block diagram illustrating an example of atimeline, in which a long-lived data session is depicted, according toembodiments of the methods and systems disclosed herein. Using existingapproaches, as noted, today's service providers can only recognizedrevenue for data sessions that have been terminated. Thus, such serviceproviders must periodically cut long running communications sessions inorder to be able to recognize the revenue for the services already usedby their subscribers. This can (and often does) result in a reducedcustomer experience. With the more frequent occurrence of long runningdata sessions (which can span several days or weeks), service providersare in a position of being unable to recognize revenue for such datasessions until long after such communications sessions have beeninitiated (e.g., recognizing revenue in the month in which the sessionwas initiated, for example). Tracking the consumed balance reservationsmakes it possible to periodically create a sub-session using informationfrom messages configured in the manner described herein, to create arated record which can be passed on to billing systems and used torecognize revenue for some of the usage in the period (e.g., month) inwhich the communications session was initiated.

In view of this, FIG. 17 depicts a timeline 1700. As can be seen in FIG.17, timeline 1700 runs from one hypothetical date to another (and, asdepicted in FIG. 17, from January 1 through March 1 of a given year).Depicted on timeline 1700 is a long-lived data session 1710, which runsfor 37 days in the given year. Such long-lived data sessions can createproblems for service providers and subscribers alike. For example, usingthe scenarios depicted earlier, long-lived data session 1710 precludesthe subscriber and the service provider from being able to know what thesubscriber's consumption and balances might be until such time as thelong-lived data session ends (February 10). However, given the abilityto make such determinations using the methods and systems describedherein, long-lived data session 1710 can be broken up into sub-sessions(depicted in FIG. 17 as a sub-session A 1720, a sub-session B 1730, asub-session C 1740, and a sub-session D 1750).

As note, long-lived data session 1710 is started on January 10 and runsuntil February 16. Without the use of consumed balances reservations, aswell as others of the techniques described herein, the revenue for thissession would only be recognized at the end of February (e.g., as ofMarch 1). Further, such recognition mandates that the session end, toallow for such recognition. Through the use of the techniques describedherein, the session can be periodically segmented into sub-sessions (inthis case, four sub-sessions), and the revenue recognized for each ofthem. In this example, the revenue for sub-session A 1720 andsub-session B 1730 can be recognized at the end of January, while therevenue for sub-session C 1740 and sub-session D 1750 can be recognizedat the end of February. The granularity of the segmentation of thesessions can be configured to meet various revenue recognitionrequirements of the service provider, and can be configured thusly in astatic, pre-configured manner, or dynamically, as communications networkconditions, policies, and other circumstances change.

An Example Computing and Network Environment

As described above, the systems described herein can be implementedusing a variety of computer systems and networks. Examples of suchcomputing and network environments are described below with reference toFIGS. 18 and 19.

FIG. 18 depicts a block diagram of a computer system 1810 suitable forimplementing aspects of the present invention. Computer system 1810includes a bus 1812 which interconnects major subsystems of computersystem 1810, such as a central processor 1814, a system memory 1817(typically RAM, but which may also include ROM, flash RAM, or the like),an input/output controller 1818, an external audio device, such as aspeaker system 1820 via an audio output interface 1822, an externaldevice, such as a display screen 1824 via display adapter 1826, serialports 1828 and 1830, a keyboard 1832 (interfaced with a keyboardcontroller 1833), a storage interface 1834, a floppy disk drive 1837operative to receive a floppy disk 1838, a host bus adapter (HBA0)interface card 1835A operative to connect with a Fibre Channel network1890, a host bus adapter (HBA) interface card 1835B operative to connectto a SCSI bus 1839, and an optical disk drive 1840 operative to receivean optical disk 1842. Also included are a mouse 1846 (or otherpoint-and-click device, coupled to bus 1812 via serial port 1828), amodem 1847 (coupled to bus 1812 via serial port 1830), and a networkinterface 1848 (coupled directly to bus 1812).

Bus 1812 allows data communication between central processor 1814 andsystem memory 1817, which may include read-only memory (ROM) or flashmemory (neither shown), and random access memory (RAM) (not shown), aspreviously noted. The RAM is generally the main memory into which theoperating system and application programs are loaded. The ROM or flashmemory can contain, among other code, the Basic Input-Output system(BIOS) which controls basic hardware operation such as the interactionwith peripheral components. Applications resident with computer system1810 are generally stored on and accessed via a computer-readablemedium, such as a hard disk drive (e.g., fixed disk 1844), an opticaldrive (e.g., optical drive 1840), a floppy disk unit 1837, or otherstorage medium. Additionally, applications can be in the form ofelectronic signals modulated in accordance with the application and datacommunication technology when accessed via network modem 1847 orinterface 1848.

Storage interface 1834, as with the other storage interfaces of computersystem 1810, can connect to a standard computer-readable medium forstorage and/or retrieval of information, such as a fixed disk drive1844. Fixed disk drive 1844 may be a part of computer system 1810 or maybe separate and accessed through other interface systems. Modem 1847 mayprovide a direct connection to a remote server via a telephone link orto the Internet via an internet service provider (ISP). Networkinterface 1848 may provide a direct connection to a remote server via adirect network link to the Internet via a POP (point of presence).Network interface 1848 may provide such connection using wirelesstechniques, including digital cellular telephone connection, CellularDigital Packet Data (CDPD) connection, digital satellite data connectionor the like.

Many other devices or subsystems (not shown) may be connected in asimilar manner (e.g., document scanners, digital cameras and so on).Conversely, all of the devices shown in FIG. 18 need not be present topractice the present invention. The devices and subsystems can beinterconnected in different ways from that shown in FIG. 18. Theoperation of a computer system such as that shown in FIG. 18 is readilyknown in the art and is not discussed in detail in this application.Code to implement the present invention can be stored incomputer-readable storage media such as one or more of system memory1817, fixed disk 1844, optical disk 1842, or floppy disk 1838. Theoperating system provided on computer system 1810 may be MS-DOS®,MS-WINDOWS®, OS/2®, UNIX®, Linux®, or another known operating system.

Moreover, regarding the signals described herein, those skilled in theart will recognize that a signal can be directly transmitted from afirst block to a second block, or a signal can be modified (e.g.,amplified, attenuated, delayed, latched, buffered, inverted, filtered,or otherwise modified) between the blocks. Although the signals of theabove described embodiment are characterized as transmitted from oneblock to the next, other embodiments of the present invention mayinclude modified signals in place of such directly transmitted signalsas long as the informational and/or functional aspect of the signal istransmitted between blocks. To some extent, a signal input at a secondblock can be conceptualized as a second signal derived from a firstsignal output from a first block due to physical limitations of thecircuitry involved (e.g., there will inevitably be some attenuation anddelay). Therefore, as used herein, a second signal derived from a firstsignal includes the first signal or any modifications to the firstsignal, whether due to circuit limitations or due to passage throughother circuit elements which do not change the informational and/orfinal functional aspect of the first signal.

FIG. 19 is a block diagram depicting a network architecture 1900 inwhich client systems 1910, 1920 and 1930, as well as storage servers1940A and 1940B (any of which can be implemented using computer system1910), are coupled to a network 1950. Storage server 1940A is furtherdepicted as having storage devices 1960A(1)-(N) directly attached, andstorage server 1940B is depicted with storage devices 1960B(1)-(N)directly attached. Storage servers 1940A and 1940B are also connected toa SAN fabric 1970, although connection to a storage area network is notrequired for operation of the invention. SAN fabric 1970 supports accessto storage devices 1980(1)-(N) by storage servers 1940A and 1940B, andso by client systems 1910, 1920 and 1930 via network 1950. Intelligentstorage array 1990 is also shown as an example of a specific storagedevice accessible via SAN fabric 1970.

With reference to computer system 1910, modem 1947, network interface1948 or some other method can be used to provide connectivity from eachof client computer systems 1910, 1920 and 1930 to network 1950. Clientsystems 1910, 1920 and 1930 are able to access information on storageserver 1940A or 1940B using, for example, a web browser or other clientsoftware (not shown). Such a client allows client systems 1910, 1920 and1930 to access data hosted by storage server 1940A or 1940B or one ofstorage devices 1960A(1)-(N), 1960B(1)-(N), 1980(1)-(N) or intelligentstorage array 1990. FIG. 19 depicts the use of a network such as theInternet for exchanging data, but the present invention is not limitedto the Internet or any particular network-based environment.

OTHER EMBODIMENTS

The present invention is well adapted to attain the advantages mentionedas well as others inherent therein. While the present invention has beendepicted, described, and is defined by reference to particularembodiments of the invention, such references do not imply a limitationon the invention, and no such limitation is to be inferred. Theinvention is capable of considerable modification, alteration, andequivalents in form and function, as will occur to those ordinarilyskilled in the pertinent arts. The depicted and described embodimentsare examples only, and are not exhaustive of the scope of the invention.

The foregoing describes embodiments including components containedwithin other components (e.g., the various elements shown as componentsof computer system 1710). Such architectures are merely examples, and,in fact, many other architectures can be implemented which achieve thesame functionality. In an abstract but still definite sense, anyarrangement of components to achieve the same functionality iseffectively “associated” such that the desired functionality isachieved. Hence, any two components herein combined to achieve aparticular functionality can be seen as “associated with” each othersuch that the desired functionality is achieved, irrespective ofarchitectures or intermediate components. Likewise, any two componentsso associated can also be viewed as being “operably connected,” or“operably coupled,” to each other to achieve the desired functionality.

The foregoing detailed description has set forth various embodiments ofthe present invention via the use of block diagrams, flowcharts, andexamples. It will be understood by those within the art that each blockdiagram component, flowchart step, operation and/or componentillustrated by the use of examples can be implemented, individuallyand/or collectively, by a wide range of hardware, software, firmware, orany combination thereof, including the specialized systems illustratedin the figures described herein.

The present invention has been described in the context of fullyfunctional computer systems; however, those skilled in the art willappreciate that the present invention is capable of being distributed asa program product in a variety of forms, and that the present inventionapplies equally regardless of the particular type of computer-readablemedia used to actually carry out the distribution. Examples ofcomputer-readable media include computer-readable storage media, as wellas media storage and distribution systems developed in the future.

The above-discussed embodiments can be implemented by software modulesthat perform one or more tasks associated with the embodiments. Thesoftware modules discussed herein may include script, batch, or otherexecutable files. The software modules may be stored on amachine-readable or computer-readable storage media such as magneticfloppy disks, hard disks, semiconductor memory (e.g., RAM, ROM, andflash-type media), optical discs (e.g., CD-ROMs, CD-Rs, and DVDs), orother types of memory modules. A storage device used for storingfirmware or hardware modules in accordance with an embodiment of theinvention can also include a semiconductor-based memory, which may bepermanently, removably or remotely coupled to a microprocessor/memorysystem. Thus, the modules can be stored within a computer system memoryto configure the computer system to perform the functions of the module.Other new and various types of computer-readable storage media may beused to store the modules discussed herein.

The above description is intended to be illustrative of the inventionand should not be taken to be limiting. Other embodiments within thescope of the present invention are possible. Those skilled in the artwill readily implement the steps necessary to provide the structures andthe methods disclosed herein, and will understand that the processparameters and sequence of steps are given by way of example only andcan be varied to achieve the desired structure as well as modificationsthat are within the scope of the invention. Variations and modificationsof the embodiments disclosed herein can be made based on the descriptionset forth herein, without departing from the scope of the invention.

Consequently, the invention is intended to be limited only by the scopeof the appended claims, giving full cognizance to equivalents in allrespects.

What is claimed is:
 1. A method comprising: receiving, at a chargingengine implemented on one or more processors, a usage request for asubscriber of a telecommunications network and, in response, creating abalance reservation for the subscriber to reserve a first portion ofpre-paid usage of the telecommunications network for the subscriber tosatisfy the usage request; receiving an update request to update theusage request, wherein the update request is received at the chargingengine, and the update request comprises information specifying aconsumed portion of the balance reservation that the subscriber hasconsumed based on the usage request; and in response to the receivingthe update request, updating the balance reservation to reserve a secondportion of the pre-paid usage of the telecommunications network based onthe update request and the usage request and, separately, creating aconsumed balance reservation for the usage request, wherein the chargingengine performs the updating, and the updating is based, at least inpart, on the consumed portion of the balance reservation.
 2. The methodof claim 1, further comprising: determining whether to grant a requestedbalance reservation, wherein the update request further comprises therequested balance reservation, and the determining is based, at least inpart, on the consumed balance reservation, and the requested balancereservation.
 3. The method of claim 2, wherein the determining isfurther based, at least in part, on: a committed balance reservation,and an available balance.
 4. The method of claim 2, further comprising:in response to a determination that the requested balance reservationshould be granted, setting an active balance reservation, wherein theactive balance reservation is set based, at least in part, on therequested balance reservation, and sending a response, wherein theresponse is configured to be sent from the charging engine to a sessioncontroller, and the response comprises information that indicates thecharging engine has granted the requested balance reservation.
 5. Themethod of claim 2, further comprising: determining whether a thresholdcould be exceeded, wherein the determining whether the threshold couldbe exceeded is based, at least in part, on the consumed balancereservation, and the requested balance reservation.
 6. The method ofclaim 5, further comprising: in response to a determination that thethreshold could be exceeded, sending a notification, wherein thenotification indicates that the threshold could be exceeded.
 7. Themethod of claim 2, wherein the updating is performed in response to adetermination that the requested balance reservation should be granted.8. The method of claim 7, further comprising: further in response to thedetermination that the requested balance reservation should be granted,determining whether one or more thresholds of a plurality of thresholdscould be exceeded, wherein the determining whether the one or morethresholds of a plurality of thresholds could be exceeded is based, atleast in part, on the consumed balance reservation, and an activebalance reservation, and in response to a determination that one or moreof the plurality of thresholds could be exceeded, sending one or morenotifications, wherein each of the one or more notifications correspondsto each of the one or more one or more of the plurality of thresholds.9. The method of claim 8, wherein the each of the one or morenotifications corresponds to one of a plurality of subscribers.
 10. Themethod of claim 1, wherein the consumed portion of the balancereservation is a portion of a prior requested balance reservation. 11.The method of claim 1, further comprising: receiving an end sessionmessage, wherein the update request is an update session message, theend session message is received at the charging engine, and the endsession message comprises information regarding a consumed portion of anactive balance reservation; and in response to the receiving the endsession message, updating the consumed balance reservation, wherein thecharging engine performs the updating the consumed balance reservation,and the updating uses the consumed portion of the active balancereservation.
 12. The method of claim 11, further comprising: committingthe consumed balance reservation to a committed balance reservation. 13.A computer system comprising: one or more processors; acomputer-readable storage medium, wherein: the computer-readable storagemedium is coupled to the one or more processors, and the computer systemimplements a charging engine; and a plurality of instructions, encodedin the computer-readable storage medium and configured to cause the oneor more processors to receive, at the charging engine implemented on theone or more processors, a usage request for a subscriber of atelecommunications network and, in response, creating a balancereservation for the subscriber to reserve a first portion of pre-paidusage of the telecommunications network for the subscriber to satisfythe usage request; receive an update request to update the usagerequest, wherein the update request is received at the charging engine,and the update request comprises information specifying a consumedportion of the balance reservation that the subscriber has consumedbased on the usage request; and in response to the receiving the updaterequest, updating the balance reservation to reserve a second portion ofthe pre-paid usage of the telecommunications network based on the updaterequest and the usage request and, separately, creating a consumedbalance reservation for the usage request, wherein the charging engineperforms the updating, and the updating is based, at least in part, onthe consumed portion of the balance reservation.
 14. The computer systemof claim 13, wherein the plurality of instructions is further configuredto cause the one or more processors to: make a determination as towhether to grant a requested balance reservation, wherein the updaterequest further comprises the requested balance reservation, and thedetermination is based, at least in part, on the consumed balancereservation, and the requested balance reservation.
 15. The computersystem of claim 14, wherein the plurality of instructions is furtherconfigured to cause the one or more processors to: in response to adetermination that the requested balance reservation should be granted,set an active balance reservation, wherein the active balancereservation is set based, at least in part, on the requested balancereservation, and send a response, wherein the response is configured tobe sent from the charging engine to a session controller, and theresponse comprises information that indicates the charging engine hasgranted the requested balance reservation.
 16. The computer system ofclaim 14, wherein the plurality of instructions is further configured tocause the processor to: make a determination as to whether a thresholdcould be exceeded, wherein the determination as to whether the thresholdcould be exceeded is based, at least in part, on the consumed balancereservation, and the requested balance reservation.
 17. A non-transitorycomputer readable storage medium storing: a first set of instructions,executable on a computer system, configured to receive, at a chargingengine implemented on one or more computing devices, a usage request fora subscriber of a telecommunications network and, in response, creatinga balance reservation for the subscriber to reserve a first portion ofpre-paid usage of the telecommunications network for the subscriber tosatisfy the usage request; receive an update request to update the usagerequest, wherein the update request is received at the charging engine,and the update request comprises information specifying a consumedportion of the balance reservation that the subscriber has consumedbased on the usage request; and in response to the receiving the updaterequest, updating the balance reservation to reserve a second portion ofthe pre-paid usage of the telecommunications network based on the updaterequest and the usage request and, separately, creating a consumedbalance reservation for the usage request, wherein the charging engineperforms the updating, and the updating is based, at least in part, onthe consumed portion of the balance reservation.
 18. The non-transitorycomputer readable storage medium of claim 17, wherein the instructionsfurther comprise: a third set of instructions, executable on thecomputer system, configured to make a determination as to whether togrant a requested balance reservation, wherein the update requestfurther comprises the requested balance reservation, and thedetermination is based, at least in part, on the consumed balancereservation, and the requested balance reservation.
 19. Thenon-transitory computer readable storage medium of claim 18, wherein theinstructions further comprise: a third set of instructions, executableon the computer system, configured to, in response to a determinationthat the requested balance reservation should be granted, set an activebalance reservation, wherein the active balance reservation is setbased, at least in part, on the requested balance reservation, and senda response, wherein the response is configured to be sent from thecharging engine to a session controller, and the response comprisesinformation that indicates the charging engine has granted the requestedbalance reservation.
 20. The non-transitory computer readable storagemedium of claim 18, wherein the instructions further comprise: a thirdset of instructions, executable on the computer system, configured tomake a make a determination as to whether a threshold could be exceeded,wherein the determination as to whether the threshold could be exceededis based, at least in part, on the consumed balance reservation, and therequested balance reservation.